The purpose of this document is to specify MacOS framebuffer driver (a.k.a. video driver) changes required to support Display Data Channel-capable displays (hereafter referred to as DDC™ displays). This document does not cover supporting DDC displays under Open Boot and Open Firmware.
DDC displays return information about the timings they support via sense line communication. DDC specifications are available from the Video Engineers Standards Association (VESA®). MacOS framebuffer drivers that support the extensions in this document gain support for DDC displays without writing code to parse the edid blocks.
Compatibility Requirements
DDC support requires:
• A framebuffer driver which support the calls documented below to return DDC blocks.
• A version of Display Manager that parses the DDC information.
Not all framebuffer hardware can read DDC information. Display Manager in System 7.6.1 and later calls supports DDC. The System 7.6.1 and later versions of Display Manager extract timing information, the display name, manufacturer and model information.
Performance
Reading the DDC information from the display which causes a slight impact on boot time and wake time (for PowerBook solutions). The Display Manager parsing of the video information has negligible performance impact. Displays generally return only a single 128 byte block of data, but the read times can be noticeable (especially at power-up) because some displays do not return DDC information until they synch to a video signal. Typical DDC reads of a single block can take from 250ms to 500ms. Display manufacturers can reduce the delay times for their displays by not requiring a synch signal before allowing DDC queries.
Version Information
DDC support will work on any machine with a DDC aware Display Manager and a framebuffer driver which supports the new status call cscGetDDCBlock. The minimum Display Manager version (gestaltDisplayMgrVers ) is 0x00020202. System 7.6.1 includes this version of Display Manager as does Display Enabler 2.2.2.
Reading DDC Information
Reading the DDC information is relatively slow and can cause screen artifacts during the reads on some displays. Framebuffers should cache the DDC information and avoid re-reading it unless the kddcForceReadBit flag is set (documented below).
Framebuffers should read DDC information as part of their sense algorithms. The next version of this document will include detailed information describing the recommended sensing algorithm which includes DDC. If you are implementing a framebuffer driver and need this information, you can e-mail hendry@apple.com directly to request an updated copy and I'll send you the next version document directly.
Framebuffers that support Open Boot need to parse the display's DDC information to the extent necessary to support the Open Boot console. The preferred implementation of an Open Boot driver caches the DDC information as an "edid" property in the device tree so it is available to the run-time driver via the Name Registry.
Framebuffer Driver API for DDC
If the framebuffer is capable of reading DDC blocks it should set the kReportsDDCConnection bit in the csConnnectFlags of the cscGetConnection call. If the framebuffer has found a DDC display that returns valid connection blocks, it should also set the kHasDDCConnection bit in the csConnnectFlags.
The cscGetDDCBlock is the only new call required to support DDC displays. It returns the requested 128-byte block of DDC information. The driver is responsible for validating the checksum of the DDC blocks. These interfaces are in the Universal Interfaces 3.0 release of video.h.
enum {
kddcBlockTypeEDID = 0 /* EDID block */
};
enum { /* flags and masks for the ddcFlags field */
kddcForceReadBit = 0, /* Force re-read of DDC information */
UInt32 ddcBlockType; /* Input -- DDC block type (EDID/VDIF) */
UInt32 ddcFlags; /* Input -- Flags */
UInt32 ddcReserved; /* Reserved */
Byte ddcBlockData[128]; /* Output -- DDC EDID/VDIF data (kDDCBlockSize) */
};
typedef struct VDDDCBlockRec VDDDCBlockRec;
typedef VDDDCBlockRec *VDDDCBlockPtr;
The ddcBlockNumber is an input parameter that specifies which block to return. The first ddcBlockNumber is block 1.
The ddcBlockType is the type of block to return. The driver should check the requested block type and return a paramErr if it does not understand the block type.
The ddcFlags are modifier flags. At this time only the kddcForceReadBit is defined. If kddcForceReadBit is set, the driver should try to re-read the DDC information from the display. If any errors are encountered during the read, the driver should return readErr and (until a successful read) cscGetConnection calls should not set the kHasDDCConnection bit.
The ddcReserved is reserved for future use and should be set to 0 by the caller. The ddcBlockData is where the driver returns the 128 byte block of DDC data.
Preferred Configurations and DDC
Framebuffer drivers should not invalidate their preferred configurations unless they detect that the configuration has changed.
During their initialization framebuffers validate their NVRAM preferred configurations. They should only invalidate their preferred configurations (set by cscSetPreferredConfiguration) when they detect that they are connected to a new display. In the absence of DDC support, framebuffers should only invalidate their preferred configuration when the display's sense code changed. With the introduction of DDC support, different displays may return the same sense code, but different DDC information. Framebuffers should invalidate their preferred configurations if DDC information indicates that the connected display has changed.
Unfortunately most framebuffer drivers have too few bytes unused NVRAM bytes to store the full DDC display signature (make and model). Given this constraint, the idea is to catch as many configuration changes as possible given using only a small amount of NVRAM. When validating the preferred configuration (PC) against the current configuration (CC) Apple recommends that Framebuffers invalidate their preferred configuration if:
1) PC and CC have no DDC and the apple sense information has changed.
2) PC had DDC and the CC does not have DDC.
3) PC had no DDC and the CC has DDC.
4) PC and CC have DDC with different checksum bytes.
This requires that the driver use a byte of NVRAM to store the DDC checksum byte and a bit to store whether DDC was sensed. The driver can optionally interpret a 0 check-sum in NVRAM to mean no-DDC. Obviously these methods will not invalidate 100% of invalid configuration changes (since the checksums might be the same or 0). Nevertheless, assuming an approximately even distribution of checksums, it will catch more than 99% of DDC display changes. To handle the rest of the cases, Display Manager does a complete configuration validation during the boot process (including parsing the DDC information) and will call the driver to switch out of invalid modes if necessary.
Framebuffers should avoid parsing DDC information
Framebuffer drivers are encouraged to avoid parsing edid blocks. Display Manager enables additional timings based on the edid. When they detect a new display, drivers should look at the established timings to pick a default timing for the new configuration.
When a DDC display is detected, the framebuffer driver should avoid using the display's sense code to mark display modes as valid or safe. Instead cscGetModeTiming calls should return all timings as not valid and not safe.
Driver writers should be aware that if DDC is not supported by the Display Manager on the user's system, the user will see only the timing to which the driver defaulted (since the current display mode is always shown). System 7.6.1 is the first System which supports DDC in the System. If you expect your driver to be used on earlier Systems, you are encouraged to ship the Display Enabler 2.2.2 or later with you driver.
Further Reading
Display Data Channel Proposal Video Electronic Standards Association
ACCESS.bus Specifications ACCESS.bus Industry Group
Designing PCI Cards And Drivers Addison Wesley
Comments and Contacts
If you have any bug reports or comments, please don’t hesitate to email. You can contact us through the following:
Email: DEVSUPPORT@apple.com (provided you have Apple developer support access)
or
Ian Hendry: Email: hendry@apple.com
Eric3 Anderson: Email: eric3@apple.com
You can also place your comments in the Developer Talk bulletin boards on the internet or other public discussion areas.
